金融行业DevOps转型案例:Capital One两年实现蝶变
背景:Capital One(Capital One Financial Corp. )是一家以投融资及基金管理为基础,集国际贸易、项目开发、投资银行业务为一体的多元化国际企业集团,总部位于美国特拉华州。
DevOps缘起:说起来这家成立只有20多年历史的银行在美国银行业里绝对算是个初创公司。公司一直都是以信息技术优势见长,尤其是在数据分析、数据科学方面,但在软件开发方面之前都是采用外包的方式,并没有被定义成公司的核心业务。
随着银行业的数字化趋势,尤其是手机上的交易量已经远远超越了传统的交易渠道,促使他们开始把软件开发作为重中之重来对待。
创始人兼CEO RichFairbank能有如此深刻的认识很不容易
痛点:Capital One的DevOps之旅开始于2014年。当时,Capital One的软件开发实践和很多传统做法没有什么不同:大量外包,瀑布模型,季度发布,手工流程,变更请求。
和KeyBank从大事故中痛定思痛不同,他们是从一个小问题反思开始的。在某次代码检查会上,大家发现一个测试失败是由于某个XML文件里的tag不配对造成的。
按理说,这么小的问题改了再提交就可以了。但是:
开发工作是由另外一家公司负责,他们需要发起漫长的变更请求;
代码修改后的构建流程(编译、测试、部署等)就需要至少2天时间
这个小小的问题让Capital One的技术团队开始反思他们的构建流程,并决定从这里下手。
他们从一个小的团队开始优化构建流程(其实就是最小版本的Pipeline – 部署流水线),最终把时间从2天缩短到几分钟。于是,这个实践逐渐在Capital One蔓延开来,所谓星星之火,可以燎原。
编者注:这是DevOps转型与落地的典型思路,小范围(局部)改进见效果,然后自发蔓延或者公司整体推广改进。
尝到甜头之后,Capital One开始认真思索企业级的DevOps策略。Capital One的DevOps框架涵盖了业务、开发、运维,最后加入了信息安全策略(对金融业安全监管尤其重要),他们称其为DevOpsSec。
Capital One的企业级DevOps框架
Capital One继续改善流水线的效率,除了开发与测试,要想真正打通流水线,还需要搞定环境/服务器的搭建和管理。之前新建一个服务器要走完62个步骤,耗时60天,开发团队的抱怨很大。
Capital One决定:直接上云!
2015年的时候还是只有开发和测试等环境在云上,到了2016年,生产环境全部上云了。
Capital One的流水线(Pipeline)
另外,Capital One发现开源真的是宝。他们不止大量的采用开源工具(”Open Source First”,非开源系统会被严格审查),还积极加入开源社区。
他们发现开源自己的工具可以让代码质量大大提高,并且大大促进了持续体验和持续学习的DevOps文化。
Capital One的开源第一(OpenSource First)策略
2015年取得的成果:
代码提交频率:从之前的不固定到每天100多次的提交
集成频率:从每月1次到每15分钟一次
部署流程:手工变成自动化
部署到QA和和Perf(性能)环境频率:从每月1次到每天4次
部署到生产环境频率:从每月或每个季度1次到到每个迭代1次
单元测试覆盖:从没概念到>90%
2016年继续改进流水线,已经能够做到:
发布到产品环境的频率:从每个Sprint一次到每天至少1次
自动发布的应用软件数量达20个
一个应用软件每天最多可以发布34次
所以说DevOps的转型可以很快。
现在,Capital One很骄傲地宣称自已有了和两年前完全不同的DNA:自己开发软件、所有环境都在云上、微服务、开源、DevOpsSec和持续交付。
确实,Capital One在DevOps之路上是远远超越了很多同业的。尤其这一旅程也只用了2年多时间。
Capital One认为转型有三个关键中的关键:
外包转向自建开发团队(外包公司要努力了)
功能团队转成产品团队(一个产品团队就像一个多兵种的行动小组)
不再区分Dev、Ops、QA、RM(Release Management),大家都在写代码,都是Engineer
转型的的三个最关键策略/实践
总结下Capital One的转型之路:
Capital One的DevOps之旅时间表
从这两个演讲中笔者听到最多的就是流水线,开源和安全。
尤其是流水线,Capital One的DevOps转型其实就是围绕着这个核心进行的,不断优化,持续改进,在整个公司推广。
Capital One总结了要做到真正的流水线,以下15个特性是必须的:
版本控制
最优的分支策略
代码静态扫描
80%以上的单元测试覆盖率
漏洞(Vulnerability)扫描
开源工具扫描
制品(Artifact)版本控制
环境自动创建
不可变服务器(Immutable Server )
集成测试
性能测试
每次提交都触发:构建、部署和自动化测试
自动化变更请求
零停机发布
功能开关
读者可以对照检验自己项目的Pipeline是否达标。
我们拭目以待Capital One在2017年在DevOps的转型之旅上会给大家带来什么样的惊喜。
本文总结自Topo Pal于DOES15和DOES16的两个演讲《Bankingon Innovation & DevOps》以及《DevOps at Capital One: Focusing onPipeline and Measurement》
本文由DevOps咖啡馆授权转载
近期好文:
干货 | 基于 DevOps 的微服务生态系统与工程实践(三)
干货 | 基于 DevOps 的微服务生态系统与工程实践(二)
干货 | 基于 DevOps 的微服务生态系统与工程实践(一)
想听许峰老师在 DevOpsDays 上海站更精彩的转型案例👇
《传统企业 DevOps 转型的若干案例》
点击“阅读原文”,关注 DevOpsDays上海站